[% setvar title Built-in functions should be functions %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Built-in functions should be functions</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Johan Vromans &lt;<a href='mailto:jvromans@squirrel.nl'>jvromans@squirrel.nl</a>&gt;
  Date: 27 Aug 2000
  Last Modified: 20 Sep 2000
  Mailing List: <a href='mailto:perl6-language@perl.org'>perl6-language@perl.org</a>
  Number: 168
  Version: 3
  Status: Frozen</pre>
<a name='NOTE'></a><h1>NOTE</h1>
<p>See CHANGES for warp-up info.</p>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>RFC 26 proposes to eliminate the distinction between functions and
operators from a language perspective.</p>
<p>This RFC proposes that all Perl built-in functions should be usable in
all ways normal functions can be used. It is part of a big consipracy
to remove the number of cases with exceptional behaviour in Perl.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>Named operators, like <code>abs</code>, can be called like functions in which
case they behave like functions. However, that's where the similarity
ends. You cannot override most builtins, and cannot tack a reference
to them.</p>
<p>There is no reason why the built-ins should be treated differently. A
famous Perl saying reads &quot;if it looks like a function, it <b>is</b> a
function.&quot; So be it.</p>
<p>In particular, it is desired that every built-in</p>
<ul>
<li><a name='can be overridden by a user defined subroutine;'></a>can be overridden by a user defined subroutine;</li>
<li><a name='can have a reference taken;'></a>can have a reference taken;</li>
<li><a name='has a useful prototype.'></a>has a useful prototype.</li>
</ul>
<a name='Overriding'></a><h2>Overriding</h2>
<p>The principle of least surprise dictates that</p>
<pre>    sub I&lt;foo&gt; { return 10 }
    print I&lt;foo&gt;();</pre>
<p>should call <i>foo</i>() and print &quot;10&quot; for all <i>foo</i>.</p>
<p>Currently, most built-ins are excluded from this. For example:</p>
<pre>    sub system { return 10 }
    print system();</pre>
<p>Instead of calling the user defined system(), the built-in is used.</p>
<p>The second line may give a warning, but only if warnings are enabled:</p>
<pre>    Ambiguous call resolved as CORE::system(), qualify as such or use &amp;</pre>
<a name='References'></a><h2>References</h2>
<p>You can call a built-in, but not take a reference.</p>
<pre>    $a = \&amp;system;
    print $a-&gt;(-1)</pre>
<p>This gives an error:</p>
<pre>    Undefined subroutine &amp;main::system called</pre>
<p>This should return a reference to the built-in instead.</p>
<p>Since <code>&amp;</code><i>foo</i> implicitly refers to the current package, it would be
acceptible to require</p>
<pre>    $a = \&amp;CORE::system;</pre>
<p>Note that this currently (5.7.0 DEVEL6806) results in the error:</p>
<pre>    Undefined subroutine &amp;CORE::system called</pre>
<p>which is surprising, if not misleading.</p>
<a name='Prototypes'></a><h2>Prototypes</h2>
<p>Currently, several built-ins do not provide prototype information.</p>
<pre>    prototype(&quot;CORE::abs&quot;)  ==&gt;  ;$
    prototype(&quot;CORE::shift&quot;)  ==&gt;  undef</pre>
<p>This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins.</p>
<a name='CHANGES'></a><h1>CHANGES</h1>
<a name='Version 3'></a><h2>Version 3</h2>
<p>Added CHANGES.</p>
<a name='Version 3, 20 September'></a><h2>Version 3, 20 September</h2>
<p>Frozen after some discussions on the mailing list. People seem to like
the idea, but worry about the prototypes. Other RFC will deal with that.</p>
<a name='Version 2, 28 Aug 2000'></a><h2>Version 2, 28 Aug 2000</h2>
<p>Add Status indicator.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>RFC 26: Named operators versus functions</p>
<p>Tom Christiansen in &lt;<a href='mailto:12231.967154045@chthon'>12231.967154045@chthon</a>&gt; (perl6-internals, Aug 24, 2000).</p>
</div>
